前面三天都還沒有真正操作 Kubernetes。

今天開始，我們建立整個系列後面會一直使用的 Lab。

架構是：

你的電腦
│
└── Docker
    │
    ├── cka-lab-control-plane
    ├── cka-lab-worker
    └── cka-lab-worker2

這三個 Docker Container 會扮演 Kubernetes Node。

我們需要三個工具

1.

Docker

負責提供 kind 建立 Node Container 的環境。

2.

kind

負責建立 Kubernetes Cluster。

Q: 那啥是 Kind 呢?

Kind (Kubernetes in Docker) :
是一個讓你透過 Docker Container 在 Local (本地端)快速執行&測試 k8s cluster 的輕量化工具。

• 核心特點:
  • 容器化節點：Kind 把每一個 K8s 節點（Node）都打包成一個獨立的 Docker 容器來運行。快速建立與銷毀：只要幾秒鐘就能利用指令架起一個標準的 K8s 叢集，非常適合用來洗掉重練或頻繁測試。
  • 支援多節點：除了單一節點（Single-Node），也能透過設定檔(config)輕鬆建立包含一個 Control Plane（控制平面）與多個 Worker（工作節點）的多節點叢集。
  • CI/CD 整合：因為輕量且不需複雜的虛擬機器架構，常被用於自動化測試與持續整合（CI/CD）流程中。

3.

kubectl

負責操作 Kubernetes。

請注意：

kind ≠ kubectl

kind 是：

蓋 Cluster。

kubectl 是：

操作 Cluster。

macOS 安裝

如果有 Homebrew：

brew install kind kubectl

確認：

kind version

Docker Desktop 也請先啟動。

確認：

docker ps

(記得要先安裝好 Docker Desktop，並且把它打開! Docker 才會啟動)

如果沒有錯誤，就代表 Docker Engine 可以正常溝通。

建立專案目錄

mkdir k8s-30days
cd k8s-30days

建立：

vim kind-config.yaml

內容：

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4

nodes:
  - role: control-plane

  - role: worker

  - role: worker

這份 YAML 不是 Kubernetes Resource。

它是：

kind 自己的 Cluster Configuration。

我們告訴 kind：

我要 1 個 Control Plane
我要 2 個 Worker

建立 Cluster

kind create cluster \
  --name cka-lab \
  --config kind-config.yaml \
  --wait 5m

逐段理解。

kind create cluster

建立 Cluster。

--name cka-lab

(小提醒 --name 是連在一起的，不是-- 空格 name 哦！)

Cluster 名稱叫：

cka-lab

--config kind-config.yaml

使用我們自己的設定。

--wait 5m

最多等待五分鐘，直到 Control Plane Ready。

看看我們是不是真的有三台 Node

kubectl get nodes

就可以看到啦：

這一刻已經完成：

Kubernetes Cluster。

為什麼 kubectl 突然知道 Cluster 在哪？

輸入：

kubectl config current-context

得到：

kind-cka-lab

kubectl 會讀：

~/.kube/config

裡面的 Cluster、User、Context 設定。

然後請記得，~/.kube/config 是一個純文字設定檔，不是可執行程式（指令）。
你若在在終端機直接輸入路徑會讓系統嘗試執行它，因而出現 permission denied 或 command not found。所以請用 cat ~/.kube/config 去進行檔案內文讀取

這份檔案是 Kubernetes 的 Kubeconfig 設定檔。它的角色相當於 kubectl 的身分證、鑰匙與通訊錄，讓 kubectl 知道要連線到哪一個叢集、以什麼身分連線，以及如何進行加密驗證。

這份設定檔由四大核心區塊組成：

1. clusters（叢集端點與信任鏈）
定義想要連線的目標叢集在哪裡：

• name: kind-cka-lab：此叢集的命名。
• server: https://127.0.0.1:50718：K8s 控制平面的 API Server 連線位址。KinD 把節點跑在 Docker 容器內，並將 API Server 映射到本機的 50718 連接埠。
• certificate-authority-data：叢集 CA 根憑證（經 Base64 編碼）。kubectl 透過它確認自己連上的確實是合法的目標 API Server，防止中間人攻擊。

2. users（使用者身分與憑證金鑰）
定義連線時所使用的身分與認證資料：

• name: kind-cka-lab：這個身分設定檔的名稱（在 KinD 中預設具有最高管理員 cluster-admin 權限）。
• client-certificate-data：使用者的公鑰憑證（Base64 編碼），由叢集 CA 簽署，記載了使用者的身分與群組資訊。
• client-key-data：使用者的私鑰（Base64 編碼），用來證明你確實持有上述公鑰憑證（雙向 TLS 認證）。

3. contexts（環境組合）
Context（情境）是將「哪一個叢集」與「哪一個使用者」綁定在一起的設定捷徑：

• name: kind-cka-lab：Context 的名稱。
• cluster: kind-cka-lab：指向上面定義的叢集。
• user: kind-cka-lab：指向上面定義的使用者身分。
• (選填) 這裡也能指定預設的 namespace。

4. current-context（目前作用中的環境）

• current-context: kind-cka-lab：告訴 kubectl 當前下達指令時，預設使用哪一個 Context。如果未來管理多個叢集（例如開發、測試、正式環境），切換此欄位就能切換操作目標。

你可以理解為：

Context
＝
我要用哪個 Identity
連哪個 Cluster

查看：

kubectl config get-contexts

如果你的電腦以前連過其他 Kubernetes Cluster，就可能看到不只一個。

所以真正操作 Production 時，非常重要的一個習慣是：

kubectl config current-context

先確認自己到底在哪裡。

不然原本只想刪 Lab Pod：

kubectl delete pod ...

結果 Context 指到 Production，那你就真的 GG 啦🤯...。

最後附上一些常用的 Context 操作指令：

• 查看目前作用中的 Context：

kubectl config current-context

• 列出所有可用的 Context：

kubectl config get-contexts

• 切換到其他 Context：

kubectl config use-context <context-name>

接著來看看 Node 本質：Kind 的底層運作原理

了解了 kubectl 是如何透過 Kubeconfig 與叢集溝通後，你可能會好奇：我們剛剛用 kind-config.yaml 建立的這 3 個節點（1 個 Control Plane + 2 個 Worker），在實體機器上到底是什麼？

我們可以直接在終端機輸入：

Bash

docker ps

你會發現，每一個 Kubernetes Node，本質上都是一個獨立運行的 Docker Container！

這正是 Kind（Kubernetes in Docker）的核心概念——它不依賴肥重的虛擬機（VM），而是直接把 Node 打包進 Container 中。從上面的輸出可以看到：

• cka-lab-control-plane：負責掌管叢集的控制節點，並將內部的 6443 埠映射到本機的 50718（這也是為什麼 Kubeconfig 裡的 server 位址會長那樣）。
• cka-lab-worker & cka-lab-worker2：負責承載一般應用程式的工作節點。

「容器裡面跑容器？」節點內部運作架構

很多人初學時會困惑：「如果 Node 只是個 Container，那未來部署的 Pod 又是跑在哪裡？」

其實，Kind 使用的 Image（kindest/node）並不是一般的輕量應用容器，而是一個具備完整作業系統環境的「節點容器」，裡面預載並運行了：

• systemd：作為 PID 1 守護行程，管理節點內的背景服務。
• containerd (CRI)：容器運行時環境。當你在 K8s 部署 Pod 時，實際上就是由這個內部的 containerd 負責拉映像檔並跑起來（即 Container in Container 架構）。
• kubelet：Node 的靈魂元件，負責定期向 Control Plane 回報節點狀態，並命令 containerd 建立或銷毀容器。
• Kubernetes 核心元件（在 Control Plane 容器內）：包括 kube-apiserver、etcd、kube-scheduler、kube-controller-manager。

看看整個 Cluster 的底層 Pod

叢集建好了，節點也都在線上，那 Kubernetes 本身是靠什麼在維持運作的？

我們來看看所有 Namespace 底下的系統 Pod：

Bash

kubectl get pods -A

-A 是 --all-namespaces 的縮寫，代表列出所有命名空間中的資源。

你會在 kube-system 與 local-path-storage 等命名空間下，看到熟悉的經典元件：

• kube-apiserver-cka-lab-control-plane
• etcd-cka-lab-control-plane
• kube-scheduler-cka-lab-control-plane
• kube-controller-manager-cka-lab-control-plane
• coredns
• kindnet / kube-proxy

前面學到的理論架構，今天全部都真實地跑在你的電腦裡了！

假如有天，弄壞了怎麼辦？Lab 的最大價值是「隨便搞」

這就是 KinD 最迷人的地方：完全沒有負擔。

如果手滑改爛 config file、Node 被玩到 NotReady，甚至整個 Control Plane 起不來，不用花半天去 Debug：

Bash

kind delete cluster --name cka-lab

幾秒鐘之內，一切乾乾淨淨。

接著再把剛才的建立指令跑一次：

Bash

kind create cluster --name cka-lab --config kind-config.yaml --wait 5m

一個全新的 3 節點叢集馬上又復活了。

所以，在之後的練習中：

• 不要害怕下錯指令
• 不要害怕把 Pod 搞壞
• 不要害怕把網路設定改壞

在 Lab 裡踩坑踩得越多，在真實環境與考場上就越穩。

Day 4 小結

今天我們完成了本機實戰環境的建置，手中正式擁有了一個標準的：

• 1 個 Control Plane
• 2 個 Worker Node

同時也摸透了 Kubeconfig 的核心架構，以及 KinD 透過 Docker 模擬多節點的底層細節。

地基打穩了，明天我們將正式進入工作負載（Workload），親手建立第一個 Pod。

明天見！